Teg

Kiro AI IDE 从入门到真香

2026/02/26 13:07 28 次阅读王梓
★ 打赏
✸ ✸ ✸

Kiro AI IDE 从入门到真香:一个让你写代码像开挂的工具

你有没有这样的体验:用 Copilot 写代码,它补全了一行,你改了三行;用 ChatGPT 生成代码,复制过来发现跑不通,又花半小时调试。AI 辅助编程这事,听起来很美,用起来总差点意思。

直到我遇到了 Kiro。

Kiro 不是又一个"AI 代码补全工具"。它是 AWS 出品的 AI IDE,基于 VS Code 内核,但做了一件其他工具没做好的事:把 AI 从"补全助手"升级成了"开发搭档"。它不只是帮你写代码,而是帮你想清楚要写什么、怎么写、写完怎么验证。

这篇文章带你从零上手 Kiro,不讲虚的,全是实战干货。

一、Kiro 的核心理念:不只是写代码

传统 AI 编程工具的工作模式是:你说一句,它写一段。像个听话但不太聪明的实习生。

Kiro 的思路不一样。它有四个核心能力,形成了一个完整的开发闭环:

能力解决什么问题类比
Spec(规格说明)需求分析 + 设计 + 任务拆解产品经理 + 架构师
Steering(导航规则)团队规范、项目约定代码规范文档
Hooks(钩子)自动化触发动作Git Hooks / CI 触发器
MCP(模型上下文协议)连接外部工具和数据源插件系统

一句话总结:Spec 告诉 Kiro 做什么,Steering 告诉它怎么做,Hooks 让它自动做,MCP 让它能做更多

Spec 做什么 Steering 怎么做 Hooks 自动做 MCP 做更多

二、Spec:让 AI 先想清楚再动手

这是 Kiro 最有价值的功能,没有之一。

你有没有遇到过这种情况:让 AI 写一个"用户登录功能",它刷刷刷写了一堆代码,但没考虑密码加密、没考虑登录失败次数限制、没考虑 JWT 过期策略。你不得不一轮一轮地补充需求,来回拉扯。

Spec 解决的就是这个问题。它把开发过程分成三步:

Requirements 你想要什么 Kiro 帮你补全细节 Design 怎么实现 你确认或修改方案 Tasks 具体步骤 Kiro 逐个执行

2.1 实战:用 Spec 开发一个评论系统

假设你要给博客加一个评论功能。传统方式是直接告诉 AI "帮我写个评论系统",然后祈祷它能猜对你的需求。

用 Kiro 的 Spec,你可以这样做:

第一步:创建 Spec

在 Kiro 的 Spec 面板点击"New Spec",输入你的需求描述:

给博客文章页添加评论功能:
- 用户可以填写昵称和内容提交评论
- 需要验证码防止垃圾评论
- 评论提交后需要管理员审核才显示
- 支持点赞功能
- IP 限流,防止恶意刷评论

Kiro 会自动生成结构化的需求文档:

# Requirements

## Functional Requirements
1. FR-1: 评论提交 - 用户填写昵称(必填,最长30字)和内容(必填,最长500字)
2. FR-2: 验证码 - 数学运算验证码,防止机器人
3. FR-3: 审核机制 - 评论默认不可见,管理员在后台审核通过后才显示
4. FR-4: 点赞功能 - 每个 IP 每天对同一评论只能点赞一次
5. FR-5: 限流 - 同一 IP 30分钟内最多提交一条评论

## Non-Functional Requirements
1. NFR-1: 评论加载不影响文章页性能
2. NFR-2: 防 XSS 攻击,所有用户输入需转义

看到了吗?你只说了五句话,Kiro 帮你补全了字数限制、XSS 防护、性能要求这些你可能忘了的细节。这就是 Spec 的价值:把模糊的想法变成精确的规格

第二步:确认设计

需求确认后,Kiro 会自动生成技术设计方案:

# Design

## Database Schema
- teg_comment: id, note_id, nickname, content, ip, status(pending/approved), created_at
- teg_comment_like: id, comment_id, ip, created_at

## API Design
- POST /comment_add - 提交评论
- GET /comment_list?note_id=xxx - 获取已审核评论
- POST /comment_like - 点赞

## Security
- 输入转义:HTML 实体编码
- 限流:内存字典记录 IP + 时间戳
- 验证码:服务端生成数学题,前端提交答案

你可以在这一步跟 Kiro 讨论、修改设计。比如你觉得"内存字典限流在重启后会丢失",可以要求改成 Redis。这种在写代码之前就把设计敲定的方式,能省掉后面大量的返工。

第三步:执行任务

设计确认后,Kiro 会把实现拆成一个个小任务:

Task 1: 创建数据库表 teg_comment 和 teg_comment_like
Task 2: 实现 comment_add 视图(含验证码校验、限流、XSS 转义)
Task 3: 实现 comment_list 视图
Task 4: 实现 comment_like 视图(含 IP 去重)
Task 5: 在 note.html 模板中添加评论区 UI
Task 6: 在 Django Admin 中注册评论管理

每个任务你可以让 Kiro 自动执行,也可以一个一个确认。执行过程中 Kiro 会自动创建文件、修改代码、运行测试。

这就是 Spec 驱动开发的魅力:需求清晰 → 设计合理 → 实现有序。不是让 AI 一股脑写完,而是像一个靠谱的工程师一样,先想清楚再动手。

三、Steering:给 AI 立规矩

你有没有遇到过这种情况:AI 生成的代码风格跟你项目完全不一样?你用 Tab 缩进,它给你 Space;你用 camelCase,它给你 snake_case;你项目禁止用 print 做调试,它给你满屏 print。

Steering 就是解决这个问题的。它是一组 Markdown 文件,放在项目的 .kiro/steering/ 目录下,告诉 Kiro 你的项目规范。

3.1 创建 Steering 文件

# .kiro/steering/coding-standards.md

## Python 规范
- 本项目使用 Python 3.9+
- 使用 f-string 格式化字符串
- 异常捕获使用 `except Exception as e:`
- 使用 type hints 标注函数参数和返回值
- 使用 logging 模块,禁止 print 调试

## 数据库规范
- 所有 SQL 使用参数化查询防止注入
- 表名使用 `teg_` 前缀
- 字符串字段不要存储 emoji(MySQL 不支持 4 字节 UTF-8)

## 前端规范
- 使用 jQuery,不使用现代框架
- CSS 写在模板的 style 标签内
- 移动端优先,使用 @media 响应式

有了这个文件,Kiro 在生成代码时会自动遵守这些规范。再也不会给你满屏 print() 调试语句了。

3.2 Steering 的三种模式

模式触发方式适用场景
Always(默认)每次对话都加载全局规范,如编码风格、安全要求
fileMatch读取匹配文件时加载特定文件类型的规范,如"编辑 Dockerfile 时遵守镜像规范"
manual手动通过 # 引用偶尔需要的参考文档,如 API 规格说明

fileMatch 模式特别实用。比如你可以创建一个只在编辑 Terraform 文件时生效的规范:

---
inclusion: fileMatch
fileMatchPattern: "*.tf"
---

## Terraform 规范
- 使用 AWS provider >= 5.0
- 所有资源必须添加 tags
- 使用 terraform fmt 格式化
- 模块版本锁定,不使用 latest

这样只有当你打开 .tf 文件时,Kiro 才会加载这些规范。既不浪费上下文窗口,又能在需要时精准生效。

四、Hooks:让 AI 自动干活

Hooks 是 Kiro 的自动化引擎。你可以设置"当某个事件发生时,自动执行某个动作"。

听起来像 Git Hooks?差不多,但更强大。因为 Hooks 的动作可以是"让 AI 做某件事"。

Event 文件保存/工具调用 Hook 匹配规则触发 runCommand askAgent 跑脚本 让 AI 干活

4.1 实用 Hook 示例

保存文件时自动 lint:

{
  "name": "Lint on Save",
  "version": "1.0.0",
  "when": {
    "type": "fileEdited",
    "patterns": ["*.py"]
  },
  "then": {
    "type": "runCommand",
    "command": "python -m py_compile ${file}"
  }
}

提交代码前自动 review:

{
  "name": "Pre-commit Review",
  "version": "1.0.0",
  "when": {
    "type": "preToolUse",
    "toolTypes": ["write"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "检查这次修改是否符合项目规范,是否有安全隐患"
  }
}

Spec 任务完成后自动跑测试:

{
  "name": "Test After Task",
  "version": "1.0.0",
  "when": {
    "type": "postTaskExecution"
  },
  "then": {
    "type": "runCommand",
    "command": "npm run test"
  }
}

4.2 Hook 事件类型一览

事件触发时机典型用途
fileEdited保存文件时自动格式化、lint
fileCreated新建文件时自动添加文件头注释
promptSubmit发送消息时自动加载上下文
preToolUse工具执行前权限检查、代码审查
postToolUse工具执行后结果验证
preTaskExecutionSpec 任务开始前环境检查
postTaskExecutionSpec 任务完成后自动测试
userTriggered手动点击按钮一键部署、一键清理

五、MCP:让 Kiro 连接一切

MCP(Model Context Protocol)是 Kiro 的插件系统。通过 MCP,你可以让 Kiro 访问数据库、调用 API、读取文档等等。

Kiro IDE MCP Protocol AWS Docs Database GitHub / K8s

5.1 配置 MCP Server

MCP 配置文件在 .kiro/settings/mcp.json

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

配置好后,你就可以在对话中直接问 Kiro 关于 AWS 文档的问题,它会通过 MCP Server 实时查询最新文档。

5.2 常用 MCP Server 推荐

MCP Server功能适用场景
aws-documentation查询 AWS 官方文档云架构开发
aws-cdkCDK 最佳实践IaC 开发
github操作 GitHub 仓库PR 管理、Issue 处理
postgres / mysql数据库操作数据查询、Schema 管理
kubernetesK8s 集群操作运维管理

MCP 的强大之处在于它是开放协议。社区有大量现成的 MCP Server,你也可以自己写一个。比如你可以写一个连接公司内部 CMDB 的 MCP Server,让 Kiro 直接查询服务器信息。

六、实战技巧:让 Kiro 效率翻倍

6.1 用 # 引用上下文

Kiro 支持在对话中用 # 引用各种上下文:

  • #File - 引用特定文件
  • #Folder - 引用整个目录
  • #Problems - 当前文件的错误和警告
  • #Terminal - 终端输出
  • #Git Diff - 当前的代码变更

比如你可以说:"看看 #Git Diff,帮我写个 commit message"。Kiro 会读取你的代码变更,生成准确的提交信息。

6.2 Autopilot vs Supervised 模式

模式行为适用场景
AutopilotAI 自主修改文件,不需要确认信任度高的重复性工作
Supervised每次修改后可以 revert关键代码、生产配置

建议:日常开发用 Autopilot 提高效率,改生产配置时切到 Supervised 多一层保障。

6.3 图片输入

Kiro 支持拖拽图片到对话框。这在以下场景特别有用:

  • 截图一个 UI bug,让 Kiro 帮你定位问题
  • 拍一张架构图,让 Kiro 帮你写 Terraform
  • 截图一个报错页面,让 Kiro 帮你排查

6.4 告别"点击允许":让 Kiro 安全地自动执行

用 Kiro 最烦的一件事:每次它要跑个命令、写个文件,都弹窗问你"允许吗?"。点一次两次还行,一个 Spec 任务下来点几十次,手都酸了。

好消息是,Kiro 提供了多层级的自动执行机制,让你既能解放双手,又不会让 AI 搞出危险操作。

Layer 1: Autopilot 模式 文件读写自动执行 Layer 2: autoApprove 白名单 信任的 MCP 工具自动执行 Layer 3: Hook 安全护栏 拦截危险操作

第一层:切换到 Autopilot 模式

在 Kiro 的 Chat 面板,找到模式切换按钮(通常在输入框附近),从 Supervised 切换到 Autopilot。切换后,Kiro 对文件的读写操作不再需要逐一确认。

但注意:Autopilot 模式下,Shell 命令和 MCP 工具调用默认仍然需要确认。这是一个合理的安全边界 -- 毕竟 rm -rf / 这种事还是让人类把把关比较好。

第二层:MCP autoApprove -- 信任特定工具

如果你确定某些 MCP 工具是安全的(比如只读的文档查询),可以在 mcp.json 里配置 autoApprove:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "autoApprove": ["search", "get_document"]
    }
  }
}

autoApprove 数组里列出你信任的工具名。只有这些工具会自动执行,其他工具仍然需要确认。这样你可以精确控制哪些操作是安全的。

第三层:用 Hooks 做安全护栏

即使开了 Autopilot,你仍然可以用 preToolUse Hook 做最后一道防线。比如禁止 AI 执行危险的 Shell 命令:

{
  "name": "Block Dangerous Commands",
  "version": "1.0.0",
  "when": {
    "type": "preToolUse",
    "toolTypes": ["shell"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "检查即将执行的命令是否安全。禁止执行包含 rm -rf、DROP TABLE、格式化磁盘等破坏性操作的命令。如果命令不安全,拒绝执行并说明原因。"
  }
}

这个 Hook 会在每次执行 Shell 命令前触发,让 AI 自己审查一遍命令是否安全。如果判定危险,会自动拦截。

推荐的安全自动化组合:

操作类型推荐策略原因
文件读写Autopilot 自动执行有 Git 兜底,随时可以 revert
只读 MCP 工具autoApprove 白名单只读操作没有副作用
Shell 命令Autopilot + Hook 护栏大部分命令安全,Hook 拦截危险操作
写入型 MCP 工具保持手动确认数据库写入、API 调用等需要人工把关

这套组合下来,日常开发中 90% 以上的操作都能自动执行,剩下需要确认的都是真正值得你关注的高风险操作。既解放了双手,又守住了安全底线。

6.5 Steering 中引用外部文件

Steering 文件支持 #[[file:相对路径]] 语法引用其他文件。这意味着你可以把 OpenAPI Spec、GraphQL Schema 等文档直接关联进来:

# .kiro/steering/api-standards.md

## API 开发规范
请严格按照以下 API 规格实现接口:
#[[file:docs/openapi.yaml]]

这样 Kiro 在生成 API 代码时,会自动参考你的 OpenAPI 规格,确保实现与设计一致。

七、Kiro vs 其他 AI 编程工具

特性KiroCursorGitHub Copilot
代码补全
对话式编程
Spec 驱动开发
Steering 规范Rules(类似)
Hooks 自动化
MCP 协议有限
多文件编辑有限
免费额度有限

Kiro 的差异化优势在于 Spec + Steering + Hooks 这套组合拳。它不只是帮你写代码,而是帮你管理整个开发流程。对于团队协作来说,Steering 统一规范 + Hooks 自动化检查,能显著减少代码 review 的摩擦。

八、最佳实践清单

用了一段时间 Kiro 后,总结几条实战经验:

1. 复杂功能一定要用 Spec

超过 3 个文件的改动,先开 Spec。让 AI 想清楚再动手,比写完再改效率高 10 倍。

2. Steering 文件要精简

不要把整本《代码大全》塞进去。只写最关键的规范,比如语言版本、命名约定、安全要求。太长的 Steering 会浪费上下文窗口。

3. 善用 fileMatch 模式

不同类型的文件用不同的 Steering。Terraform 文件有 Terraform 的规范,Python 文件有 Python 的规范,互不干扰。

4. Hook 不要太多

每个 Hook 都会消耗执行时间。只设置真正有价值的自动化,比如保存时 lint、任务完成后测试。

5. MCP 按需启用

不用的 MCP Server 设置 "disabled": true。每个活跃的 MCP Server 都会占用资源。

6. 给 Kiro 足够的上下文

#File 引用相关文件,用 #Terminal 提供错误信息。上下文越准确,AI 的输出质量越高。

7. 迭代式开发

不要期望一次对话就搞定所有事。先让 Kiro 搭骨架,再逐步完善细节。就像跟同事协作一样,沟通越多,结果越好。

九、总结

Kiro 的核心价值不在于它的 AI 模型有多强(虽然确实不错),而在于它提供了一套结构化的 AI 辅助开发流程

  • Spec 让你在写代码前想清楚要做什么
  • Steering 让 AI 遵守你的项目规范
  • Hooks 让重复性工作自动化
  • MCP 让 AI 能访问你需要的一切资源

这四个能力组合在一起,Kiro 就不再是一个"代码生成器",而是一个真正的开发搭档。它帮你思考、帮你规范、帮你自动化、帮你连接工具链。

如果你还在用 AI 工具"一问一答"地写代码,不妨试试 Kiro 的 Spec 驱动开发。当你第一次看到 AI 帮你从需求分析到代码实现一气呵成的时候,你会理解什么叫"真香"。

Kiro 官网:https://kiro.dev,免费使用,开箱即用。

✸ ✸ ✸

📜 版权声明

本文作者:王梓 | 原文链接:https://www.bthlt.com/note/14809800-TegKiro AI IDE 从入门到真香

出处:葫芦的运维日志 | 转载请注明出处并保留原文链接

📜 留言板

留言提交后需管理员审核通过才会显示